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LI 7 ANSWER 1 OF 1 USPATFULL 

TI Method for managing a cache hierarchy having a least 

recently used (LRU) . , ^ 

global cache and a plurality of LRU destaging local caches 

containing 

counterpart datatype partitions 
PI US 5717893 19980210 

AB A method for managing a cache hierarchy having a fixed 

total storage . ^ . n 

capacity is disclosed. The cache hierarchy is logically 

partitioned to 

form a least recently used (LRU) global cache and a 

plurality of LRU , . 

destaging local caches. The global cache stores objects of 

all types and ^ . 

maintains them in LRU order. In contrast, each local cache 

is bound to . . 

objects having a unique data type T(i), where i is 

indicative of a 

DataType. Read and write accesses by referencing 

processors or central 

processing units (CPU's) are made to the global cache. 

Data not , ^ 

available in the global cache is staged thereto either 

from one of the ^ 

local caches or from external storage. When a cache full 

condition is / v ^ 

reached, placement of the most recently used (MRU) data 

element to the x. ^ 

top of the global cache results in an LRU data element of 

type T(i) 

being destaged from the global cache to a corresponding 

one of the local ^ ^ ^ ^ 

caches storing type T(i) data. Likewise, when a cache full 

condition is i_ i, i n 

reached in any one or more of the local caches, the local 

caches in turn 

will destage their LRU data elements to external storage. 

The parameters 

defining the partitions are externally supplied. 
SUMM The placement and management of cache memories between one 
or more 

processors and one or more main storage devices such as 
hard disks are 

very common for high-speed sophisticated computer systems. 
It is well ' 

known that the performance of such computer systems is 

intimately . 

related to the performance of the cache memories. The 

prior art shows , * > • 



various efforts to improve the cache memory performance. 
These efforts 

included the use of multi-level caches for hierarchical 

management , ' the 

use of separate caches for instruction and for data, the 

division of 

caches into many partitioned caches for parallel and 
simultaneous 

access by a plurality of processors, and many other 
methods for 

connecting the caches to the processors and different ways 
of managing 

the caches. 

SUMM The following pertinent patents represent the state of the 
art in 

managing cache memories with either 1) a hierarchical 
multi-level 

structure and/or 2) a partitioned cache configuration: 
U.S. Pat. No. 

4,442,487 by Fletcher et al (Apr. 10, 1984) entitled 
"Three Level Memory 

Hierarchy Using Write and Share Flags", assigned to the 

same assignee as 

the present invention, describes a system of multiple 

caches between 

several processors and several storage devices. In this 

system of 

caches, each processor has its own local cache and there 
is one cache 

shared between all the processors. 

SUMM Although Fletcher's patent solves the "cross interrogation 
problem" that 

often occurs when more than one processor can update 
shared data, the 

cache system was managed in a fragmented fashion because a 

separate 

Least Recently Used (LRU) -List was maintained for each 
partition and a 

block of data can belong to only 1 of 4 types . 
Furthermore, because the 

data types stored in the caches were not identified, the 

cache 

management system did not provide a mechanism whereby some 
types of data 

blocks could be kept in the caches longer than other types 
in response 

to the more recent requests of that types of data by the 

central 

processing unit (CPU) . 

SUMM The Mattson patent provide£^a . separate LRU-List of block 
number and 



shared cache location and a separate available space list 
of empty 

shared cache locations for each process. Furthermore, the 
replacement 

within a partition is based on the LRU List for that 

process and every 

process uses the most recently referenced entries m its 

LRU list to , ^ ^ 

determine a hit to the shared cache, and a shared cache 

control is 

necessary to collect hit and miss data from each process 

and , 
periodically reallocate shared cache space to each 

process. It is . 

limited by the same difficulties as that was encountered 

in the 

Flecther^s patent discussed above. 

SUMIVI Reference should also be made to Brenza, U.S. Pat. No. 
4,905,141, . . 

entitled "Partitioned Cache Memory With Partitioned 

Lookaside Table . 

(PLAT) For Early Assignment Identification", issued Feb. 

27, 1990, and 

assigned to the same assignee as the present invention, 

which describes 

a system with one shared cache between several processors 

and several 

storage devices. This cache is partitioned into M 
sub- caches. These M 

sub-caches are equally sized caches between one processor 

with a memory 

having M+l ports for concurrently making requests to a 

storage device or 

devices. This cache organization is illustrated m FIG. 

Ic. Simultaneous 

cache accessing in up. to M of the M different caches may 

be made by M .... 

processor requests if the request on each port i is found 

in the cache 

serving port i. If a miss is detected from any of the M 
port requests, 

that request is sent to every one of the M caches via port 
M+l. If this 

is also a miss, the block is requested from mam storage 

and can be put 

into any one of the M caches. This allows for 
M-parallelism in accesses 

to the M caches . 

SUMM The Brenza patent may be considered to be more flexible in 
allowing a 

data block to go into any one of the M caches. However, 
because a 



separate LRU list must be maintained for each partition 

and the t t • 

replacement within a partition is based on the LRU List 

for that 

partition only, Brenza patent is also limited by the same 
difficulties 

as experienced by all the cache management systems where a 

fragmented 

cache control scheme is utilized. 

SUMM U.S. Pat. No. 4,503,501 by Coulson et al (Mar. 5, 1985) 
entitled 

^•Adaptive Domain Partitioning of Cache Memory Space", 
describes a 

system with one shared cache between several processors 
and several 

storage devices. This cache is partitioned into M 
sub-caches. These M 

sub-caches are called partitions PI, P2, . . . , PM. 

Partition PI 

holds blocks of size Bl, partition P2 holds blocks of size 

B2 

and' partition PM holds blocks of size BM, where Bl, B2, . 
. . , BM are 

all different. As a further refinement, every sub- cache or 
partition 

is divided into fixed sized "domains" where each "domain" 
is large 

enough to store bl blocks of size Bl, or b2 blocks of size 

B2 

or bM blocks of size BM. In this manner, there are Dl 
domains in 

partition PI capable of holding a total of Dl*bl blocks of 
size Bl, D2 

domains in partition P2 capable of holding a total of 

D2*b2 blocks of 

size B2, . . . , and DM domains in partition PM capable of 

holding a 

totaj. of DM*bM blocks of size BM. An example of this cache 
organization 

is shown in FIG. le with M=3, Dl=2, D2=5, 03=3, Bl=4, 
B2=3, B4=2, bl=3, 

b2=4, and B3=6. 

SUMM Each sub- cache or partition is managed by maintaining an 
LRU List of 

blocks in that partition. When a block of size Bi is 
requested, the 

LRU List for partition Pi is examined to see if the block 
is present. 

If the block is in the list, the list entry gives the 

cache address of 

the block, the LRU List is updated to make the requested 

block the most 



recently referenced block and the cache controller sends 
the data to the 

requestor. If the requested block is not in the list; the 

cache 

controller uses the LRU entry in the list to determine the 
cache address 

of the data to be replaced with the requested block of 
data, and after 

replacement has occurred, the replaced block is removed 

from the LRU 

list and the LRU List is updated to make the requested 
block the most 

recently referenced block and the cache controller sends 
the data to the 

requestor . 

SUMM The Coulson patent is again limited by managing the cache 
system in a 

fragmented manner in maintaining a separate LRU-List for 

each 

partition and using the LRU List for data replacement 
within a 

partition. This patent also disclosed that the number of 
domains in a 

given partition can be dynamically changed to make more 
efficient use 

of the cache. 

SUMM However, dynamically changing a domain in Coulson involves 
the removal, 

of ail the data blocks in the domain from the cache in 
order to make the 

switch, which may result in sudden changes in performance. 

Furthermore, 

the domain switching algorithm tends to treat all 
DataTypes equally in 

that the ratio of partition stages to number of partition 

frames is 

the same for all data types (DataTypes) . This method of 
partitioning 

is a "minimum loss" rather than a "maximum gain" method 
because there 

are no definitive correlations between the heuristic 
allocation of 

domains to each partition and the types of CPU processes 
requesting 

the cache data. The dynamic variation of cache partition 
alone may npt 

result in hit ratio improvements. 

SUMM Furthermore, it is another object of this invention to 
provide a means 

for logically partitioning uhe cache into M+1 sub-caches 

or 



partitions where M is an integer and some of the subcaches 

are . . . 

implemented for storage of data records of specific 

DataType thus 

allowing some DataTypes to remain in the cache longer than 

other 

DataTypes . 

SUMM Furthermore, it is another object of this invention to 
provide a means 

whereby all logical partitions of the cache are globally 

managed and 

controlled from a common data structure accessed by a 
single cache 

manager . 

SUMM Furthermore, it is another object of this invention to 
provide a means 

whereby the partition sizes can be periodically 

reconfigured in an 

attempt to achieve higher hit ratios than could be 
obtained from a set 

of fixed partition sizes. 

SUMM Furthermore, it is another object of this invention to 
provide a means 

whereby the partition sizes can be periodically 

reconfigured by 

altering a single data structure accessed by a single 

cache manager 

without having to move or alter any data actually stored 
in the cache, 

except for the possibility of having to push some data, 
which has been 

altered, out of the cache. 

SUMM It is further an object of this invention to broaden the 
scope of the 

applications of the invention by replacing each "cache", 

"sub- cache"', or 

"partition" mentioned in the background references or 

other literature 

with the "Partitioned Cache" of this invention. This 

substitution is 

easily achievable since each "cache", "sub-cache", or 

"partition" 

mentioned in the reference literature uses a single 
LRU-List for 

management and control of a single blocksize "cache", 

"sub" cache" or 

"partition" and, by changing that LRU-List to the LRU-List 

of this 

invention, each "cache." "sub- cache " , or "partition" 
becomes a more 



efficient "Partitioned cache", "Partitioned sub-cache" or 
"Partitioned partition" which has the potential of 
producing a 

higher number of hits. 

SUMM The objects of the invention are satisfied by making a 

logical ^ ^ . 

subdivision of a cache memory array. The present invention 

teaches a . . ^ ^ 

cache management system for operation with at least one 

computer CPU. 

The cache management system is capable of fetching a 

plurality of data 

blocks from a system storage hierarchy for temporary 

storage and for 

rapidly transferring the data blocks to the CPU tor 

processing. The 

cache management system comprises a cache array having a 

global . . _ 

partition and a plurality of DataType partitions. The 

global 

partition and DataType partitions have cache memory stores 

capable 

of storing a plurality of data blocks. The cache 
management system 

further has a cache manager which is capable of receiving 

a data memory 

request from the CPU requesting a read or write operation 
of at least 

one data block. The cache manager further has a cache 

manager memory, 

and the cache manager memory has a cache manager directory 

and a 

DataType Table. The cache manager directory comprises a 

plurality of . . ^ • • 

data entries wherein each data entry is indicative ot a 

data block name, 

a data block DataType, a cache array address of a data 

block, a pointer 

pointing to the cache array address of a more recently 

used data block, . 

a pointer pointing to another data entry m the cache 

manager directory 

reflecting the relative positioning of the data entry m 

the directory, 

an address of an available cache array space, a maximum 

number of data 

blocks for a cache partition, and a status control data 

item. The ' ' . • 

DataType table has a plurality of DataType entries wherein 

each DataType ^ m 

entry comprises a data block category name and a DataType 

identifier. , ' 



The data memory manager further has a cache management 
means whereby 

upon receipt of a data memory request from the CPU, the 
management means 

executes the memory request for the CPU and updates the 

cache manager 

directory. The cache management means further examines the 
DataType 

table and moves the data blocks in and out of the global 

and the 

DataType partitions in the cache array in accordance with 

the 

DataTypes. The present invention teaches a cache manager 
which manages 

the cache system by use of a single cache manager 
directory to maintain 

a logically partitioned cache. The cache memory is 
maintained to have 

an integrated configuration and therefore is capable of 

achieving a 

close to optimal cache management efficiency. 

DRWD FIG. 4c is a schematic illustration showing the details of 
a 

Partition-Entry row in the cache directory table referring 

to 

partitions of the cache array. 
DRWD FIG. 4f is a schematic illustration showing some possible 
ways of using 

the name field in an LRU-List-Entry and a Partition-Entry. 
DRWD FIG. 6 is a schematic illustration of the cache directory 
table as set 

forth in this invention with entries in the table used to 
illustrate a 

particular partitioned cache organization and LRU order 
among the 

blocks in the cache array for the present invention. 
DRWD FIG. 8 is a schematic illustration of steps required to 
change the 

partition sizes in a Partitioned Cache as PO diminishes. 
DRWD FIG. 9 is a schematic illustration of steps required to 
change the 

partition sizes in a Partitioned Cache as PO diminishes. 
DRWD FIG. 13 is a schematic illustration of a flow chart 
describing the 

process executed by the cache manager to change partition 
sizes in the 

partitioned cache of this invention for the present 
invention . 

DETD The objects of the invention are satisfied by logically 
subdividing a 

solid-state memory into one global partition and a 

plurality of , * • ' 



DataType partitions, i.e., M partitions, each capable of 
holding an 

integer number of blocks of data where each block is of 
the same size. 

The sum of all the blocks in all the partitions is the 

total number of 

blocks that can be stored in the cache. The size of each 

partition, 

i.e., the number of blocks in each partition, is 
determined by an . . 

analysis process external to this invention whereby it is 

determined . 

that such a partitioning is likely to produce equal to or 
higher hit 

ratios than could be produced by any of the cache schemes 

referenced in 

the background or other literature. A schematic 
illustration of a cache 

organization as set forth according to the present 
invention is shown in 

FIGS . 2 and 3 . 

DETD Partition 0, PO, of the M+l cache partitions is assigned 
to storage 

of blocks of all DataTypes and each other partitions, PI, 
P2 . . . , 

PM are assigned to storage of blocks of only one DataType, 
Tl T2 , . . , 

' , TM respectively. When an application requests a block of 
data, B, the 

cache manager must find B, tag B with a DataType, Tb, make 
room for it 

in partition PO of the cache, and make it the Most 
Recently Used block 

in PO. There are several cases to consider to summarize 

the cache 

manager operations, but IN ALL CASES the entry for B in 
the LRU-List 

shows where B is stored in the cache. If the request is a 
WRITE, then 

the data can be overwritten, and the dirty bit m the 
LRU-List entry 

turned on. If the request is a READ then the data can be 
transferred to 

the requestor. For both READ and WRITE requests the 

current type, Tb, is 

stored in the LRU-List entry, and B is made the Most 
Recently Used, MRU, 

block in partition PO . 
DETD Case 1 (a cache hit) is if the cache manager finds an 
entry for B in the 

LRU-List and determines that Block B is at cache location 

L and is in 

partition PO, then the cache manager makes B the MRU entry 
in PO by 



moving the entry for B in the LRU-List from its current 

position to the . , ^ ^ 

top of the LRU-List and block B must be either sent to the 

requester or . • ^ ^. • t 

received from the requester and written into location L 

with a . 

corresponding setting of the dirty bit. 
DETD Case 2 (a cache hit) is if the cache manager finds an 

entry for B in the . t ^ 

LRU-List and determines that B is at cache location L ana 

partition Pa (Pa not=PO) . Then the cache manager logically 
moves (the 

block B in the cache is not moved) B from Pa to PO by 

removing the entry . . 

for B in the LRU-List from its current position and moving 

it to the top . ^ , 

of the LRU-List. This will effectively increase the number 

of blocks in , ■ ^ 

PO by one and decrease the number of blocks m Pa by one. 

If PO was not . ^ i 

full the cache manager is done with the LRU-List and block 

B must be . ^ ^ 

either sent to the requester or received from the 

requester and written , ^ ^ ■ 

into location L with a corresponding setting of the dirty 

bit. However, i ■ 

if PO was full, then PO has one too many blocks m it and 

the cache 

manager must determine which block, block C, is the LRU 

block in PO and , ^ _ 

logically remove C from PO and decrease the number of 

blocks in PO by . ^t, 

one. If the LRU-List entry for block C indicates that L 

had DataType Tc, , ^ ^ ,^r,TT v,n i 

then the cache manager must logically make C the MRU block 

in Pc and ^ 

increase the number of blocks in Pc by one. If Pc was not 

full then the . , ■ ^ ^ 

cache manager is done with the LRU-List, but if Pc was 

full then PC has 

one too many blocks in it and the cache manager must 

determine which . 

block, block D, is the LRU block in Pc and logically 

remove D from Pc . ^ -r^ -i, 

and decrease the number of blocks in Pc by one. If the 

entry for D in , u. 

the LRU-List had the dirty bit turned on then the cache 

manager must . , ^ 

write the data in that cache location to disk, turn off 

the dirty bit, 

and mark the location as empty. Block B must then be 

either sent to the . ' • • 



requester or received' from the requester and written into 

location L > 

with a corresponding setting of its dirty bit. 
DETD When the cache manager is instructed to change the 

partition sizes it ^ . ^ x^r 

must take the following actions assuming PO is full. If PO 

is to be made 

smaller by KO blocks, the cache manager must move KO 

blocks from PO to , ^ , • 

the other partitions and decrease the number of blocks m 

PO by KO. . . ■ ^ 

The DataType of each block in the set KO determines into 

which , ^, 

partition it must be put. If Kl of them go to PI, then the 

number of -r^ r.n • 

blocks in PI needs to be increased by Kl, etc. If PO is to 

be made , _ . 

larger by KO blocks, the cache manager must move KO blocks 

from the ^ ^ i^-, i 

other partitions to PO and increase the number of blocks 

in PO by KO. 

The blocks selected from the other partitions must be 

carefully done 

so that all the blocks that logically end up in PO are 

more recently ^ . ,_v, 

referenced than any block remaining in one of the other 

partitions. 

Again if Kl blocks logically move from PI to PO then the 
number of 

blocks in PI must be decreased by Kl, etc. If any 

partition PI, P2 , . . . ^ t.t_ 

. . , PM has too many blocks in it, for example if Pb has 

Kb too many . , . 

blocks in it, then the Kb LRU blocks m Pb must be removed 

from the ' ^- , • ^ ^v. 

cache by: writing the corresponding data to disk if the 

dirty bit is . . ^ i . ^v, 

turned on; marking the entry not m cache; and marking the 

cache 

locations as empty. 
DETD In this way partition sizes can be changed at 
pre-determined times in 

an attempt to maximize the number of hits to a cache. 
DETD It should be noted that, in all of the above cases, when 
the desired 

size of PO is zero, the "Partitioned Cache" of this 
invention becomes 

similar to other partitioned caches in the literature, and 

the new . . ^ 

management methods proposed for this invention can be used 

to manage 

those caches. It should also be noted that any cache m 
the literature , ' 



that is managed from a single LRU-List can easily be 

changed to the . . , ^ • 

"Partitioned-Cache" of this invention with the obvious 

advantages. ... ^, ... 

DETD As discussed above, the logical partitioning, the periodic 

changing of . . ^ i 

partition sizes, the dynamic categorization of blocks ot 

data into ^ ^„ ^ ^ 

disjoint DataTypes, the ability to "re-fetch" old data 

blocks, and the 

control of all the above by a single cache manager 

operating on two _ , ^ ^ i 

tables (a table to store an LRU-List with embedded control 

entries, and , 

a table to store how the cache manager should assign 

DataTypes to blocks 

of data) stored in memory used by the cache manager, are 

all designed to a_ ^ ^ ■ ^ 

be used in a solid-state cache memory subsystem operating 

to contain . . . ^ • ^ 

data' permanently stored on disk memory m anticipation ot 

its being 

requested by a process running on a host computer. Tne 
cache memory 

subsystem may either be separate from a host computer 

having its own . . ^ 

processor and memory, ..or a task running m a host computer 

like the 

bufferpool manager in many database systems. 
DETD Again referring to FIG. 3, the present invention is 
concerned with five 

operations performed by the cache manager. 1) In response 

to a request 

from a process external to this invention, such as system 
start up, the 

cache manager can logically partition the storage space m 
the cache 

array 36 into M+l subportions, sub-caches, or "partitions" 
PO, PI, . . 

PM, with each partition able to store CO blocks, CI 
blocks , . . . 

and CM blocks respectively, where C0+C1+C2+ . . . +LM 

equals the total ^ 

number of blocks that can be stored m the cache array 36. 

The cache 

manager 34 can achieve this logical partitioning of cache 

array 36 by T-,Ton 
initializing certain entries in a Table 2 (see FiGb . 

4a-4f) stored in ^ ^ ^ 

memory 42. 2) As each write or read request from host 

process (s) 38 is 

received by the cache manager 34, the cache manager 

assigns 1 of M . ' • * 



possible DataTypes to the requested block. Over time the 

same block of ^ ■ !_ 

data may be assigned different DataTypes according to who 

(which process 

38) made the request, what data was requested, or why the 
data was 

requested, the information being provided by the host 

process 38. The 

cache manager 34 determines the DataType to assign to each 

block of data . 

by consulting a Table 1 (FIG. 5) stored m memory 42. 3) 

In response' to . -u 

a sequence of requests from process (s) 38 running on host 

processor (s) . 

10, the cache manager 34 can cause blocks to logically 

"flow through" 

the cache array 36 in a novel manner that can increase the 

number of . 1 1 

hits to the cache by allowing blocks belonging to all 

DataTypes to be . ■ x 

treated equally (by sharing the use of one partition) as 

long as they 

are "young" or frequently re-referenced, and then forcing 
each block 

into its own partition, according to its DataType, as they 

"age" or i 
have not been referenced for a long time, so that blocks 

belonging to 

certain DataTypes will remain in the cache longer than 

blocks belonging . -u • 

to other DataTypes. The cache manager 34 can achieve this 

logical "block 

flow" in cache array 36 by updating certain entries m a 
Table 2 (see 

FIGS. 4a-4f) stored in memory 42. 4) In response to 
requests from a . 

process external to this invention, the cache manager 34 

can . ^ . . . 

periodically change the number of logical partitions and 

sizes of the • ^ 

logical partitions in the cache array 36 (so that a higher 

number of ^ v. 

hits to the cache array 36 can be obtained than could be 

obtained with 

any fixed set of partition sizes) . The cache manager can 
be changing 

the partition sizes concurrently with performing its 
normal operation. 

The cache manager 34 can achieve this dynamic logical 

partition size 

change in the cache array 36 by updating certain entries 
in a Table 2 

(FIGS. 4a-4f) stored in memory 42. 5) In response to the 
availability of 



space in the cache array 36 and a set of pre-determined 
rules provided 

by a process external to this invention, the cache manager 
34 can or 

cannot "re- fetch" blocks of data that are currently not m 

array 36, but were previously in cache array 36, because 
they have a 

high probability of being requested by a process 38 

running on the host ^ . ' ^ 

processor 10. The cache manager 34 can determine which 

blocks to . . rr. 1^1 n 

"re-fetch" by referring to historical entries m a Table 2 
(FIGS. 4a-4f) 

stored in memory 42, 
DETD In order to better understand the operation of this 
invention it is 

necessary to first describe the "cache directory", or 

Table 2, that the . . 

cache manager 34 uses to control the logical partitioning 

of the cache 

array memory 36. FIGS. 4a-4f depict the preferred 
embodiment of the . 

cache directory as a table which is stored m the cache 

manager memory ^ . ^ 

42. This cache directory contains two doubly linked lists. 

The first ^ ^ • ^ 

double linked list refers to a least recently used list 

(LRU List) of 

blocks of data and their associated DataType, status, and 

control 

information currently residing in the cache. The second 
double linked 

list is an available space list of empty block locations 
in the cache 
array . 

DETD Referring to FIG. 4a, the preferred embodiment of the 
cache directory 50 . ^ ^ 

is stored as a table with plural 32-byte rows, each of 

which contains 

information about the blocks of data stored m the cache 

array. FIG. 4a , . 

shows there are four types of rows. Empty Rows (er) 52, 

LRU List Entry ■ -, 

rows (le) 56, Partition Entry rows (pe) 58, and Available 

Cache Array . 

Space rows (av) 54. An Empty Row (er) can become either a 

LRU List Entry ^ ^ 

(le) row or an Available Cache Array Space (av) row and, 

in a similar 

manner, (le)'s and (av) ' s can become (er)'s. 

DETD The next eight bytes, bytes 04-11, (na) 62 are used to 
store a "name" 



for a requested block. Two examples of such names are 

given in FIG. 4f. , , , ^ 

The next four bytes, bytes 12-15, (ca) 63 are used to 

store a cache , ^ w ^ 

array address for a block of data. The next four bytes, 

bytes 16-19, , . , ^ 

(LF) 64 are used as an LRU-List forward pointer and store 

the row number ^ 

(of a row in the cache directory table 50) of the next 

entry, after the . 

current entry, toward the bottom of the LRU-List. The next 

four bytes, . ^ , j 

bytes 20-23, (LB) 65 are used as an LRU-List backward 

pointer and store ^ 

the row number (of a row in the cache directory table 50) 

of the next , , ^ ^. 

entry, before the current entry, toward the top of the 

LRU- List. The 

next four bytes, bytes 24-27, (PF) 66 are used as a 

Partition-List , , ^ • 

forward pointer and stores the row number (of a row m tne 

c a. chG 

directory table 50) of the next entry, after the current 

entry, toward ^ ^ , ^ 

the bottom of a Partition-List. The next four bytes, bytes 

28-31, (PB) . ^ ^ 

67 are used as a Partition-List backward pointer and store 

the row ^ ^ ^ 

number (of a row in the cache directory table 50) of the 

next entry, 

before the current entry, toward the top of the 
Partition-List. 

DETD FIG. 4c shows the 32 -byte row that makes up each 
Partition-Entry 58. ■ ^ • ^ 

The first two bytes, bytes 00-01, (en) 60 contain 16 bits 

status/control information which is described more fully 

with respect to 

FIG. 4e, The next two bytes, bytes 02-03, (PN) 68 are used 

as r- 

partition name PO, PI, P2, . . . , or Pn. The next four 
bytes, ^ytes reserved. The next four bytes, bytes 08-11, (MB) 

69 are used , ^ ^ 

to store the maximum number of blocks that can be stored 

in this ^ . ^ 

partition of the cache array 36. The next four bytes, 

bvtes 12-15 

(NB)'70 are used to store the number of blocks that are 

currently stored „^ <_ « 

in this partition of the cache array 36. The next four 

bytes, bytes ^ ■ ^ j 

16-19, (LF) 64 are used as .an LRU-List forward pointer and 

store the row 



number (of a row in the cache directory table 50) of the 

next entry,. , ^ ^.i, 

after the current entry, toward the bottom of the 

LRU-List. The next ^ ^ . ^ 

four bytes, bytes 20-23, (LB) 65 are used as an LRU list 

backward • ^v, v, 

pointer and store the row number (of a row m the cache 

directory table 

50) of the next entry; before the current entry, toward 

the top of the 

LRU-List. The next four bytes, bytes 24-27, (PF) 66 are 

used as a , w 

Partition-List forward pointer and store the row number 

(of a row in ^, 
the cache directory table 50) of the next entry, after the 

current , . . 

entry, toward the bottom of a Partition-List . The next 

four bytes, . . . . ^ ^ i ^ 

bytes 28-31, (PB) 67 are used as a Partition-List backward 

pointer and. , , ^ . ^ 

store the row number (of a row in the cache directory 

table 50) of the ^ ^ ^ ^ 

next entry, before the current entry, toward the top of 

the 

Partition-List . 

DETD . 

Bit 00 (er) = 

1 means this row is empty. 

0 means this row has data in it. 

Bit 01 (le) = 

1 means this row is an LRU-List-Entry 56. 

0 means this row is not an LRU-List-Entry 56. 

Bit 02 (pe) = 

1 means this row is a Partition-Entry 58. 

0 means this row is not a Partition Entry 58. 

Bit 03 (ac) = . „ . 

1 means this row is an Available-Space List Entry 54. 

0 means this row is not an Available-Space List Entry 54. 

Bit 04 (pz) = 

1 means the block referred to by this entry is 

in partition PO . 

0 means the block referred to by this entry is 
not in partition PO . 

Bit 05 (ic) = ... 

1 means the block referred to by this entry is in 

the cache array. 

0 means the block referred to by this entry is 
not in the cache array. 

Bit 06 (db) = 

1 means the block referred to by this entry 
has data different from the data for a block 

with the same name that resides on disk (the block 

is dirty) . It has been wri.tten into by a host process and 

has not been written to disk. 



0 means the block referred to by this entry 
has data the same as the data for a block 

with the same name that resides on disk (the block 
is clean) . It has not been written to disk. 

Bit 07 (it) = ^. . 

1 means the block referred to by this entry 
is in transit, either being filled from 
disk or host or being sent to disk or host 

0 means the block referred to by this entry 
is not in transit, it is neither being 
filled from disk or host nor disk or host. The 
remainder of the bits, bits 08-15, are reserved 
for other uses. 

gg^pg Referring to FIG. 4f, two examples of "names" for blocks 

of data are . n i 

given. The first example, 100, illustrates a row called 

"a" in the cache t • *. m 4- 

directory table 50 which is a row with an LRU-List-Entry 

56 with the . . ^ ■ j= ^ 

name field, na, filled in. This name field is referred to 

as a[na], and ^ • u 

in this case has a [na] =dev, cyl , hd, Rec where dev=device 

cyl = cylinder ^ . , 

#^ hd=head #, and Rec=record or block # which is a common 

way to address n -i m 

a block of data stored on disk. The second example, 101, 

illustrates a n r-^ -u • u • ^ 

row called "b" in the cache directory table 50 which is a 

row with an • i n ^ ■ rpv, • 

LRU-List-Entry 58 with the name field, na, filled in. inis 

name field is 

referred to as b[na], and in this case has 
b[na]=DBID,PSID, Sec, Page 

where, DBID=database #, PSID=pagespace #, Sec=dataset 

partition #, and 

Page=page # which is a common way to name a page m a 

database system. n ^ „ „ 

The third example, 102, illustrates a row called "c in 

the cache . . . _ . 

directory table 50 which is a row with a Partition-Entry 

54 with the ^ . . ^ . ^ ^ 

name field, PN, filled in. This name field is referred to 

as c [PN] , and , ^ ^ . ^ . 

in this case has c[PN]=Pt # or the number for partition t. 

Any unique^ ^^^^ ^^^^ fields (na) or (PN) and the 

invention will 

still operate. . . . 

DETD One of the major advantages of this invention is the 

ability of the 

cache manager to manage the partitions such as shown m 
FIG. 2 from a . ■ 



single table stored in memory 42 used by the cache manager 

34. WhereaS' , o,- , 

FIG. 2 shows a Partitioned Cache array holding 25 blocks 

with each ^ ■ 

block belonging to one of 5 DataTypes, FIG. 6 illustrates 

the preferred . . , 

embodiment of a cache directory table showing 50 rows and 

14 columns . . 

with entries necessary for multiple partition management 

^ Partitioned Cache array holding 18 blocks with each block 

belonging to . ^ ^ t 

one of three DataTypes, Tl, T2 , or T3 . Six of the control 

bits for each 

row are shown in the first six columns of FIG. 5. The 

first 6 rows . 

contain Partition-Entrys and have the cn(pe) bit=l. The 

partition . , „ ^ 

names, given by the PN field of the Partition-Entry 

(column 7 in the . , „, .,t, ^ • t j 

table) are PO, PI P5 respectively. The MB field 

of the , n J 

partitions indicate that partition PO can hold a maximum 

°^ ^ blocks, PI 7 blocks, P2 3 blocks, and P3 0 blocks. The NB 

field of the . . . ^ , , ^i 

partitions indicate that each partition is full, currently 

storing 

the maximum number of blocks . 
DETD In the preferred embodiment, the PF field 118 (column 13 

of FIG. 6) of ^ • 

the row for partition PO (row-0) has the unique role of 

giving the row 

number of the first entry in an LRU-List used to manage 

^^^^ "Partitioned-Cache" . Since the value in P0[PF]=12, the 

entry in row 12 . , ^ ^ v, 

119 of the table starts the LRU-List needed by the cache 

manager, and ^ , , , ^ ^ ^ 

represents the most recently referenced MRU block of data 

in the cache 

array. This row is said to be the top entry m the 
LRU-List. Referring ^ • -, ^ 

to row-12 of FIG. 6, it is not empty (row-12 control field 

(cn) bit 0 . „ 

(er) is 0 or R12 [cn (er) ] =0 ) , it is an LRU-List-Entry 

(R12 [cn(le) ] =1) , it , , . . ^ 

is not a Partition-Entry (R12 [cn (pe) ] =0) , it is not an 
Available-Space-Entry (R12 [cn (ac) ] =0) , it is in partition 

PO 

(R12 [cn(pz) ] =1) , and the block of data represented by this 

entry is in . . _ .„ 

the cache array (R12 [cn (ic).l =1) - Continuing across Row 12 

of FIG. 6, the 



DataType of the block of data represented by this entry is 

type 1 

(R12[DT]=1), this block has the name "name-01" 
(R12 [na] =name-01) , the . ^ • ^ 

block of data represented by this entry is stored m frame 

11 in the , 
cache array (R12 [ca] =11) , the next most recently used 

(referenced) block . ^ ^i. ^ i,i 

is referred to by the entry stored in row 33 of the table 

(R12 [LF] =33) , , . ^ ^ . V, 

and the least recently used (LRU) block is referred to by 

the entry , ^ . . . 

stored in row 17 of the table (R12 [LB] =17 ) . In a similar 

manner, row 33 ^ i 

has the same control bits, and the DataType of the block 

represented by this entry is type 2 (R33[DT]=2), this 

block has the name 

■■name-02" (R33 [na] =name-02) , the block of data represented 

by this entry t ..v, 

is stored in frame 04 in the cache array (R33 [ca] =04 ) , the 

next most ^ . j= 

used block is referred to by the entry stored m row 20 of 

the table ^ ^ i ■ 

(R33 [LF] =20) , and the least recently referenced block is 

^6f 6r"ired to by 

the entry stored in row 12 of the table (R33 [LB] =12 ) . 
DETD Whereas FIG. 6 illustrates the data as it is stored in the 

cache • , 

directory, FIG. 7 presents the LRU-List in top to bottom 

order where for 

any LRU-List-Entry X (corresponding to row-X in the cache 

directory r , ■ s x. 

table) only fields X[na], X [DT] , and X[cn(ic)] are shown. 

For any . 

Partition-Entry Pt (corresponding to row-t m the cache 

directory ^ ^ 

table) only fields Pt[PN], Pt [MB] , and Pt [NB] are shown m 

FIG. 7. . ^ V- ^ 

DETD FIG. 7 illustrates the preferred embodiment of the steps 

necessary for a 

cache manager to manage a "Partitioned-Cache" array 

holding 18 blocks 

with each block belonging to one of three DataTypes, Tl, 

T2 , or T3 . The . ^ . „tt t ■ ^ 

LRU-List illustrated in Step 1 of FIG. 7 is the LRU-List 

represented- by • ^ ^ v. 

the entries in the cache directory of FIG. 6 and shows an 

LRU-List for , . „ 

three DataTypes, M+l=4 partitions of block sizes C0=8, 

Cl=7, C2=3, and , 

C3=0, corresponding to partitions PO, which can hold 

blocks of data of • . ■ 



any DataType (Tl, T2, or T3), PI which can hold only 

blocks of DataType „^ ^ r,-, 

Tl, P2 which can hold only blocks of DataType T2, and P3 

which can hold . 

only DataType T3, respectively. Each Step in FIG. 7 

illustrates an 

LRU-List containing both LRU-List-Entries and 

Partition-Entries, but _ ^ • n-rr-c 

only a part of the complete entries described in FIGS. 

4a-4f and , ^-^ ^ ■ 

illustrated in FIG. 6 are shown in FIG. 7 because that is 

sufficient to 

demonstrate the invention. 
DETD Referring to the LRU-List for Step 1 120 m FIG. 7, the 

LRU-List -Entry is the most recently referenced block in 

the cache array. 

It has a name [na] ="Name-01" 122, a DataType [DT] =Tl 124 

and an in cache , , , ^ • ..v,^ 

bit •(ic)=l 126 that says that the block is present in the 

cache array. 

The next most recently referenced block m the cache array 

s 

[na] ="Name-02" , [DT]=T2, and (ic)=l that says that the 

block is present ^ w 

in the cache array. Similar statements can be made about 

the top eight . , ^ ..v, 

LRU-List-Entries shown in Step 1. The ninth entry from the 

top of the , ^ • T ^ 

LRU-List is a Partition-Entry 128. It has a name field 

[PN]=PO, . ^ ^ 

meaning it refers to Partition- 0, a Maximum Number of 

Blocks f i-Gld 

[MB] =08, and a Total Number of Blocks field [NB] =08 

meaning that all . 

blocks in the partition are filled. The position m the 

LRU-List of 

the Partition-Entry for partition PO 128 is not an 

accident. It is . , ^ -^u 

ninth from the top because the eight blocks above it with 

(ic) =1 in the ^ ^ . ^ 

LRU-List are precisely the eight blocks allocated to 

partition PO . • ■ i 

DETD The 28-th entry from the top of the LRU-List is also a 

Partition-Entry ^ ^ ■ ^ ■ -i 

130. It has [PN]=P1, meaning it refers to Partxtion-1, a 

Maximum ^ >t v. ^ 

Number of Blocks field [MB] =07, and a Total Number of 

Blocks field . . 

[NB]=07 meaning that all blocks in the partition are 

filled. The . . ^ ^ 

position in the LRU-List of the Partition-Entry for 

partition PI 130 



is also not an accident. It is 28-th from the top because 
there ^re 

exactly 7 LRU-List -Entries above it having DataType Tl and 

^^^^^^ betSLn the Partition-Entry for PI and the Partition-Entry 

for PO. . . , 

DETD The 17-th entry from the top of the LRU-List is also a 

Partition-Entry . ^ 

132 with [PN]=P2, [MB] =03, and [NB]=03, meaning that all 

blocks ^^^^^^^^^ filled. Partition-Entry P2 is 17-th from the 

because there are exactly 3 LRU-List-Entries above it 

having DataType T2 . . m ^ ^ m =r.^ 

and (ic)=l lying between the Partition-Entry for P2 and 

the 

Partition-Entry for PO . 
DETD Still referring to Step 1 of FIG. 7, the 10-th entry from 

the top of the , ,.,.1. r■^,^a^ m 

LRU-List is the last Partition-Entry 134, has [PN]=P3, 
[MB]-0, ^^^^^Q^ meaning it can store no blocks and no blocks are 

^■""■"■^^^^it. ^Partition-Entry P3 is 10-th from the top because there 

9.re exactly 

zero LRU-List-Entries above it having DataType T3 and 
(ic)=l ly^JJI^^ Partition-Entry for P3 and the Partition-Entry 

for PO 

DETD 'Assume that the request is for "name 12" and that an entry 

for that name , . . 

is located in row-31 (see FIG. 6) of the cache directory 

and the 14-th , . 

item in the LRU-List (see FIG. 7). The cache manager is 

now ready to ^ ^ ^ ■ *.v,^ 

proceed with satisfying the request and updating the 

LRU-List. Referring , , 

to FIG. 6, since R31 [cn ( ic) ] =1 , the cache manager can send 

or receive , , ^ 

data into the associated block located at cache frame 

R31[ca]=16 in the 

cache array. Having satisfied the request, the cache 

manager must then • -,11,, 

determine which partition contained the page, logically 

remove the . 

page from that partition, and logically put the page as 

the referenced page in partition PO . Those skilled in 

^^^will recognize that removing an item from a double linked 
list ^^^^^p^g matter of changing four pointer values in the list. 
Thus , the . . ■ 



entry for Name 12 can be removed from the list shown in 
Step 1 of FIG^^ ^^^^ ^ DataType of T2 , it was in partition 

°^ ^"Partitioned Cache". Referring to FIG. 1, the Partition 
Entry for . located in the Table as being row 2 . Since Name 
logically been removed from P2, the Total Number of 

Blocks, R31[NB], . ^ ^ V no no -in c;t-f=r, 

must be reduced by one as is illustrated by P2 13 8 m Step 
2 of FIG 7 

DETD Referring to FIG. 6 again, the Partition-Entry for PO is 
easily ^^^^^^^ ^ table. Since Name 12 should be 

logically a^"^®^^^ ^^^^^ Number of Blocks PO [NB] must be increased 
by one as is 

illustrated by PO 140 in Step-2 of FIG. 7. . ^ ^ 

DETD The LRU-List shown in Step 2 of FIG. 7 is inconsistent. 

Partition-Entry for PO 140 indicates that PO can hold a 

maximum^of^S^ and 9 have been assigned to it. This inconsistency 

can be pQ ^he LRU-List-Entry 142 just above PO . 

One skilled , . , k,, 

in the art will recognize that this can be done by 

changmg^G^pointer^^ doubly linked LRU-List. However since entry 
142 '^^^pj^.^^j.ypg Tl, the block for Name-08 142 was logically 
moved po[NB] field of PO 146 must be decreased by one and 

the PI f^^^^^ xsxast be increased by one as shown in Step 

DETD ^"""The LRU-List shown in Step 3 of FIG. 7 is still 

inconsistent. The , 

Partition-Entry for PI 144 indicates that PI can hold a 

maximum^of^7^ and 8 have been assigned to it. This inconsistency 
can be ^^^JJ^^^^^^ toward the top of the LRU-List until it is 

above the first ^ , • n n 

entry encountered with DataType Tl and (ic)=l, then 

subtracting one from . „^ ^ * c-tz-i n 

the P1[NB] field in PI 148 as shown in Step 4 of FIG. /. 

^^''''^ ''would leave an LRU-List-Entry 150 below PI with DataType 

Tl and (ic)=l, v „ ^ ^v,, 

the cache manager must make (ic)=0 for the entry 

corresponding to , ' • ' 



"name-24" by either writing the corresponding block of 

data in the cache • n v,t -.^^ 

array to disk, or otherwise make this space available and 

add ^^^^^^^^^j^-Lg cache address to the available list. To make the 

^^^"^^ available, an empty row is located in the hash table by 

generating a , • ^v. if 

random name, hashing it to a row number in the table, i£ 

the row is , , ■ ^i^^ 

empty an empty row has been found, otherwise examine the 

next row in the ^-u ^. 

table, etc., until an empty row is found. To make that row 

an available , , _ „v.^^ 

space row, make (er)=0, (av)=l. Put the cache frame number 

in the [ca] , ..^ „ ^ 

field, and add this entry just after the "top" of 

available-space list , ^ 

entry located as the last row of the cache directory of 

FIG . 6 . Then , „ ^ « 

(ic)=0 in the "name 24" 152 entry as shown m Step 4 of 

FIG. 7. . . • ^ ^ 

DETD Referring to Step 4 of FIG. 7, the LRU-List is consistent, 

but the cache . ^ • ^ i ^ r.-F 

manager now has a unique opportunity as a direct result o£ 

^^^^ Partitioned Cache structure. P2 154 has P2 [MB] =3 and 

P2[NB]=2, meaning . ^ 

that' there is a hole (it is not full) m partition 2. 

Thus, the cache . -u. 

manager can "re-fetch" the first LRU-List-Entry 156 below 

P2 into the ^ ^ . , 

cache array at an available cache array location (as 

obtained from the v.^ 
available- space list) , Then P2 154 can be moved down to be 

located just tv, 
below "name 15" 156 and P2 [NB] increased by one to =3. In 

many cases, . -u-^ j 

this re-fetching of old data can increase the hits and 

response time to . , ^ i_ --^ 

the cache because (in this case) it could be better to 

have an old entry ^ r> - m 

of DataType T2 in the cache than an old entry of DataType 

Tl (which was _ „^ ^ • -, 

pushed out of the cache in Step 3 of FIG. 7) . Details 

performed by the ^ ^v. 

cache manager to implement the above changes to the 

LRU-List are given ^ • 

in the flow diagrams of FIGS. 11 and 12. Those skilled m 

the art can . . 

recognize these flow diagrams as descriptive of a program 

stored in ^ ^ ■ „ 

memory 42 executable by a computer processor located m 

the cache 



manager 34 of FIG. 3 which will cause bytes in the cache 
directory^^Jlso^ memory 42, to be updated and thus reflect the 
actions 

described in FIG. 7. . ^. ^ • ^ 

DETD According to the present invention, periodic changing of 

partition^^^ is provided in accordance with an external request 

^° manager. For example, if the partitions were allocated as 
shown in^^^ ^ ^^^^ ^ ^^^g^ ^^^^^ ^2=3, and C3=0 and an 

external^^^^^^ requested that they be changed to C0=4, Cl=3, 
C2=4, ^"^^J^lll^^ manager would change the respective [MB] fields 
m the p^^j.^^.^Q^_gj^^j.ieg po, Pi, P2, and P3 to be 4, 3, 4, 

and 7 as shown 

in Step 1 of FIG. 8. . . ■ ^ ^ 

DETD The LRU-List shown in Step 1 of FIG. 8 is inconsistent. 

"^^^ Partition-Entry for PO 170 indicates that PO can hold a 
maximum^of^4^ and 8 have been assigned to it. This inconsistency 
can be toward the top of the LRU-List. First, 

past Name^OS^^ subtracted from the [NB] field of PO and 

one is added to i, ; c. 

the [NB] field of PI, then past Name- 07 whereby one is 

subtracted from ^^^^^ ^^^^ ^.^^^ 

P2, then past , ^ ^, ^r^i^i/^ /^-f 

Name- 06 whereby one is subtracted from the [NB] field of 

PO and °ne^js^^ ^^^^ ^.^^^ ^^^^ ^^^^ Name-05 whereby 

subtracted from the [NB] field of PO and one is added to 
the tNB]^^field^^^ partition PO is consistent. The LRU-List would 
then be as 

shown in Step- 2 of FIG. 8. _ 
DETD The LRU-List shown in. Step 2 of FIG. 8 is also 

inconsistent. The ^ , 

Partition-Entry for Pi 180 indicates that Pi can hold a 

maximum^of^3^ and 9 have been assigned to it. This inconsistency 
can be solved ^^^^^ manager moving PI 180 toward the top of the 
LRU-List ^ith DataType Tl and (ic)=l are below 

PI. The process _ ' . ' 



of moving PI up the LRU-List past entries with [DT] =T1 is 

facilitated by . , , ^ • rnin 

the use of partition forward and backward pointers IPFJ 

and t-he cache directory table shown in FIG. 6. 

Dg 1 3. i 1 s 

performed by the cache manager to implement this movement 

°^ ^ Partition-Entry are given in the flow diagram of FIG. 13. 

ThosG 

skilled in the art can recognize that this flow diagram is 
descriptive ^^^^^^^ stored in memory 42 executable by a computer 

nrocessor , . , . n 

located in the cache manager 34 of FIG. 3 which will cause 

bytes in the , ^ ^ 

cache directory, also., stored in memory 42, to be updated 

and thus . 

reflect the actions described m FIG. 8. 
DETD The LRU-List shown in Step-3 of FIG. 8 is still 

inconsistent. The ^ , ^ u i ^ 

Partition-Entry for P2 182 indicates that P2 can hold a 

maximum of 4 . rr,^ . • * v.^^^,, 

blocks and 5 have been assigned to it. This inconsistency 

can be solved ^ ^ ^ *.v.^ 

by the cache manager moving P2 182 toward the top of the 

LRU-List until . ^ . v. n ^ 

one LRU-List-Entry with DataType T2 and (ic)-l are below 

P2 As each 

LRU-List-Entry with DataType T2 and (ic)=l is put below 

P2 , the cache , j ■ ^ 

manager must see to it that: the block corresponding to 

the 

LRU-List-Entry with DataType T2 and (ic)=l in the cache 

array is written ^ ^ ^- ^ »-v,^ 

to disk if its data is different from that on disk; the 

bit is changed , ^^^^^ . , . 

to (ic)=0; and one is subtracted from the [NB] field m 

P2 . The result 

of this operation is shown m Step-4 of FIG. 8. 
DETD Referring to Step 4 of FIG. 8, the LRU-List is consistent, 

but the cache ^ . ^ -i^^c 

manager now has a unique opportunity as a direct result of 

'^^^^ Partitioned Cache structure. P3 184 has [MB] of 7 and [NB] 

°^ ° meaning that there 7 empty blocks or holes in partition 

P2. Thus, the ^. , , 

cache manager can "re -fetch" up to seven blocks of 

DataType T3 from . ^ ^ ^, 

disk. The blocks to re- fetch can be determined by the 

cache manager by ^ , . t • ^ ■ i 

moving P3 184 toward the -bottom of the LRU-List until 

either the end of 



the LRU-List is reached or 7 blocks of DataType T3 are 

above P3 in' the . ^ / • \ n 

list. As each LRU-List-Entry with DataType T3 and (ic)=0 

is put above . , ^,.^11 

P3, the cache manager must see to it that: the block 

corresponding to , , . v « • c _ v, ^ 

the LRU- List -Entry with DataType T3 and (ic)=0 is fetched 

from disk, . . ^ n .- • ^v, 

tagged with DataType T3 and written into a free location 

in the cache , . -.^ ^ ^ 

array; the bit is changed to (ic)=l; and one is added to 

the [NB] field , . ^ ^ 

in P3. If the cache manager elects to do this re-fetchmg, 

the result is , . ^ • , i 

as shown in Step 5 of FIG. 8 where there is still one 

empty block in P3 . <r,.^^ 

186 because the bottom of the LRU-List was reached after 

only 6 . . ^ £ .-v, 

re- fetches were found in the historical part of the 

LRU-List. " . ^ JZ-, ^■ 

DETD FIG. 9 gives a second example of applying the flow diagram 

shown in FIG. . ^ ^ 4. ^-rr^ o 

13 to change Partition Sizes where, m contrast to FIG. » 

where PO . ■,. 

gets smaller, PO gets larger. According to the present 

invention, . . -j ^ • 

periodic changing of partition sizes is provided in 

accordance with an „ , ■ ^ ^v,^ 

external request to the cache manager. For example, it the 

partitions ^rv o 

were allocated as shown in Step-1 of FIG. 7 to be C0=8, 

Cl = 7, C2 = 3, and v, 

C3=0 and an external process requested that they be 

changed to C0=10, 

Cl=2, C2=4, and C3=2, the cache manager would change the 

respective [MB] 

fields in the Partition-Entries for PO 190, PI 192, P2 

194, and P3' 196 ^ ^ 

to be 10, 2, 4, and 2 as shown in Step 1 of FIG. 9. 

DETD Referring to the LRU-List shown in Step 1 of FIG. 9, the 
Partition-Entry for PO 190 indicates that PO can hold a 

maximum of 10 . „^ • « ^v, 

blocks and 8 have been assigned to it. The size of the 

this partition , , ^ ^ ^.v, 

can be increased by moving PO 190 toward the bottom of the 

LRU-List . ^ ^ / • X -, 

until two additional LRU-List-Entries that have (ic)=l are 

above PO . . . 

However, PO cannot be below any other partition so P3 must 

a.lso be 

pushed down the LRU-List. Thus, the cache manager attempts 
to move^PO ^^^^ ^^^^ Name-09,- byt- since Name-09 has DataType 
T3 and the 



[NB]=0 field of P3 indicates that no blocks are allocated 
between^P3 ^^^^ added to the bottom of the P0,P3 chain 

and P^^^^^^g ^^^^ pQ p3 ^^^^ past Name- 10 where because its 

cache manager adds one to the [NB] field of PO and 

subtracts one from 

the [NB] field of PI, then down past Name- 11 where tne 

cache ,^^^3] fiel^j of po 190 and subtracts one 

from the [NB] . ^ • ^ m rpv,^ 

field of P2 194, at which point PO 200 is full. The 

resulting LRU List 

is shown in Step-2 of FIG. 9. . . ^ 

DETD The LRU-List shown in Step-2 of FIG. 9 is inconsistent 

because the . . , ^ 

Partition-Entry for PI 204 indicates that PI can hold a 

maximum of 2 . , ^ t-v,-: ^ 

blocks and 6 have been assigned to it. As before, tnis 

inconsistency can , ^ ^v, ^ ^ 

be solved by the cache manager moving PI toward the top ot 

the ^^^^^^^^ ^ LRU-List-Entries with DataType Tl and (ic)=l are 

below PI . Each , , ■ v ■ 

time an LRU-List-Entry of DataType Tl and (ic) =1 is put 

below ^^^^^g^^^^gggj. subtracts one from the [NB] field of PI, 

sets (ic)=0', and, .,■ i_i 1 ■„ i-v,^ 

if the dirty bit=l, writes the corresponding block m the 

cache array . . , 

back to disk. The result of this operation is shown in 

DETD ^ Referring 'to Step 3 of FIG. 9, the LRU List is consistent, 

but the cache . , ^- ^ i 

manager again has a unique opportunity (as a direct result 

of ^^^^p^^^^^^Q^g^_c^^he structure) to "re-fetch" previously 

reauested blocks . 1 

into the cache array in anticipation of getting additional 

cache hits . 4. • v, 

and lowering the response time of requesting host 

processes. P2 206 has ^ -^.t 1 ^v- 

[MB] =4 and [NB] =2 meaning that there are 2 empty blocks or 

holes ^^^^^^^^^^ p2 Thus, the cache manager can re-fetch up to 

two blocks of , £ ^ V, v,^ 

DataType T2 from disk. The blocks to re- fetch can be 

determined by the , , ^ .= *-v,^ 

cache manager moving P2 206 toward the bottom of the 

LRU-List until . . t, ^ o V^l^^l^o r^f 

either the end of the LRU-List is reached or 2 blocks of 
DataType T2 are .. _ ' 



above P2 in the list. As each LRU-List -Entry with DataType 

T2 and (ic)=0 . t-h = h . 

is put above P2, the cache manager must see to it that. 

the ^l°^^^^g3p^^^.ng to the LRU-List-Entry with DataType T2 and 
^^""^^^ fetched from disk, tagged with DataType T2 and written 
into a f^ee^^^^ cache array; the bit is changed to (ic)=l; 

and one^is^^ ^^^^ ^.^^^ ^^^^^ manager elects to 

^° ^'^^^re- fetching, the result is as shown in Step 4 of FIG. 9. 
DETD Referring to Step 4 of FIG. 9, the LRU-List is consistent, 

^""^ ''^^manSgSr again has a unique opportunity (as a direct result 
of ^^^^p^^^^,..Qned Cache structure) to re- fetch previously 
requested^blocks^^^^^ array in anticipation of getting additional 

cache hits . ^ ^ . 

and lowering the response time of requesting host 

nrocesses P3 208 has , ^ 

P [MB] =2 and [NB] =0 meaning that there are 2 empty blocks or 

holes 1^^^^^^.^^ ^^^he manager can re-fetch two blocks of 

DataType^T3 ^^^^^ ^^^^ ^.^^ DataType T3, write them into free 

locations^in^^^^ array, set (ic)=l, and add two to the [NB] field 

Jache^manager elects to do this re-fetching, the result is 

shown in Step 

5 of FIG 9 

DETD Those skilled in the art will recognize that there has 

been described a ^ ^ ■ ■ ^ ■ „ ^ 

partitioning and control system for dividing up a 

solid-state' memory ^ ■ ^ ^ 

which fulfills the needs of the art and objects of the 

invention^^_,^^^^ above. Specifically, a method for dynamically 
assigning^^^^^^^^ to blocks of data based on who requested them, 

how they were , , • j 

requested, the intent of the request, and the kind of 

information stored 

in the block is described. 
DETD While the invention has been shown and described with 

^^'^^^^e^odiments above, it will be understood by those skilled 
in the art^ various changes in forms and detail may be made 
therein without 



or 



departing from the essence, scope, and teaching of the 

^^^^^^ ^Furthermore, it will be appreciated that the method of the 

invention has . -v, j 

applicability beyond embodiments specifically described. 

For example: 1) ^ ^ ^ ^ 

some of the control mechanisms can be used to control a 

cache that is v, j 

physically partitioned (i.e. an in-host memory cache and 

disk, ca.ches) / 

2) by' allowing for a hierarchy of DataTypes (e.g. Tl 

consists of T 1 

subtypes Tib, Tic, . . . , Tin) , any or all of the 

partitions in the ^ ^- ■ 

embodiment described above could themselves be divided 

into a p^^^.^^j_Q^g^ Cache and be managed by the same cache manager 

using the . . „ ^ • 

same LRU-List by simply including Sub-Partition-Entries 

(e.g. P^^^^ . . . , Pin) in the LRU-List. 3) any cache, subcache, 

partition of a cache that is managed by a single LRU List 

(i.e. those . . ^ • ^ ..v, 

given in the references) could be partitioned into the 

Partitioned^^ described in this invention, with the advantages 

given in the ^ • „ ^ • ^ • ^ 

references added to the advantages of the Partitioned 

Cache given 

herein. 4) Since the embodiment of the cache directory 

illustrated in , . t ■ 

FIGS. 4a-4f and FIG. 6 orders blocks globally in one list 

and at the ^ -^i ^ 

same time orders and controls the flow of the blocks in 

esch 

partition, that cache directory can be used by other 

software programs ^. 

to control partitioned caches that have an arbitrary 

logical flow of . ^ • ^ 

blocks from one partition to another, provide arbitrary 

orderings . ^ c 

other than LRU, and allow blocks of differing sets of 

DataTypes to be in , , , , n j ^- 

each partition. That is, a requested block could first go 

partition P3 , then flow to partition PI, then to PO, and 

when pushed ^ . 

from PO, go into either PI, P2, or P3 according to its 

DataType. The ^ ^ ^v, ^v,^ 

mechanism for such control is provided by the cache 

directory structure, . ^ ^ •„ c-rr-c 

the preferred embodiment -of _ which is illustrated m Fibb . 

4a-4f and FIG. 



6 . 

CLM What' is claimed is: . ^ v, • 

1. A method for managing a cache hierarchy having a fixed 

total g^^jj cache hierarchy being sited in a data path 

coupling^a^^^^^_^ to an external storage subsystem, comprising the 

steps of: (a) , , . T_ ^ 

logically partitioning said cache hierarchy to form a 

iBcist iTscBntly 

used (LRU) global cache and a plurality of LRU destaging 
local caches 

each local cache i being bound to objects having a unique 
data ^yP®_j^^ ^ ^ being an identifier designating one of the 
plurality^of^loca identifier designating the unique 

data tyP^g^^g^^ ^^^^^ ^. (13) responsive to access commands 

from ^^p^Q^gggQ^^ storing objects of all types in said global 

cache and , , , -, • t dtt ^v^<=.v 

maintaining them in said global cache m LRU order, 

objects^being staged ^^^^^ gather from one of the local caches or 

from ^'^J^^g^^^^ storage subsystem if not present in said local 

caches; (c) upon 

the global cache attaining a cache full condition, 

destaging an LRU ^ ..v, i^^^i 

object of type T(i) from the global cache to the local 

cache storing^ ^^^^^ ^ ^^^^^ ^^^^ condition under an LRU global 

°^ °^^cache being one where the storage of an additional object 

in. a cache 

results in the destaging of at least one object in LRU 
order; ^nd^(d)^^ ^^^^ ^^^^^ caches attaining a cache 

condition, destaging an LRU object from said one or more 

local caches to 

the external storage subsystem. 
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